Follow-up to #11628

Motivation

• similar to Argo CD and many other projects, we can use esbuild instead of TS etc to significantly speed up build times
  • (as esbuild is written in Go and compiled instead of using interpreted TS/JS)
  • we don't use any Babel or TS plugins, so I think this codebase is a good candidate for that
  • it also simplifies the build process as well, removing & replacing many other deps
  • caveats:
    • esbuild does not do type-checking, so we have to run tsc --noEmit as part of the lint phase
    • esbuild-loader does not currently support React Fast Refresh (c.f. about hmr react-refresh/babel  privatenumber/esbuild-loader#250, Using with esbuild-loader? pmmmwh/react-refresh-webpack-plugin#366)
      • react-hot-loader was replaced by React Fast Refresh and is deprecated / hasn't received an update in 2 years
      • that being said, esbuild is significantly faster than using Babel or TS for builds, so hot reloading is nice but not necessary
        • also hot reloading can be buggy
        • plus, in my experience, the dev build often falls back to a full page refresh anyway

• resolve various warnings in the build, during the install, and in the console
• replace multiple deps with 1

Modifications

• remove babel-loader, ts-loader, react-hot-loader, and source-map-loader
  • note that source-map-loader is still present in the yarn.lock as it is used under-the-hood by other deps
    • but the warnings from directly using source-map-loader are no longer present in the build
    • and the bundle size shrank a bit, seemingly bc there is no autolinker etc dep in the bundle, but potentially other reasons (I did not check in-depth)

• add esbuild-loader

• add tsc --noEmit to the lint script

• add isolatedModules config to ensure compatibility with esbuild's compiler

  • since it has no type-checking, it can't do full program analysis, meaning there are certain types it doesn't support

  • same as when using Babel to compile TS

  • fix some resulting type-check errors:

    • upgrade argo-ui to use export type syntax: fix: Use type export for interface reexports argo-ui#552
    • pin types-ramda due to requiring newer TS: build(ui): improve performance with esbuild-loader #12516 (comment)
    • workaround: add Intl typings missing in older TS: a4511f6

• remove mdl.hot etc usage of react-hot-loader

Related config / performance changes

• further optimize dev builds by using cheaper eval sourcemaps as recommended by Webpack for performance

  • prod builds should always have highest quality sourcemaps, so do not change those
  • this was also discussed in chore: remove ui source map for production build #11716 (comment)

• remove unused react-paginate exclude

  • it's not a dep we currently use; it doesn't exist in the lockfile
    • (nor in argo-ui's lockfile, of which all prod deps would be in Workflows's lockfile as well)

Verification

1. yarn build works fine
2. make start UI=true works fine and UI seems to function as expected

Performance Testing

some simple performance testing when running natively on macOS, taken directly from Webpack's reported stats:

• before:
  • prod build: ~65s
  • dev build: ~22s
  • dev rebuild: ~1.8s
• after:
  • prod build: ~50s (~25% faster)
  • dev build: ~16s (~25% faster)
  • dev rebuild: ~.8s (~50% faster)

Future Work

these are not as good improvements as I would have liked, which mean there are bigger bottlenecks elsewhere

• e.g. Webpack itself (analysis, source maps, running loaders), sass-loader, etc
  • sass has been slow in the past and is ripe to be replaced with more modern PostCSS as well
  • switching to esbuild directly may further improve these stats
    • i.e. instead of Webpack + esbuild-loader
• independently building argo-ui instead of as part of the Workflows (and CD) builds per argo-ui: future state of this repo argo-ui#453
• optimizing more deps per UI: Code Split larger and/or less-used paths for smaller initial bundle #12059 and related comments, such as removing moment, consolidating similar deps, etc